1. Field of the Invention
The present invention relates to software development in a networked environment. In particular, it relates to a method and system for automatically assisted generation of composite applications which are composed of a plurality of components, and in which method a template means defines the requirements and specifications of the components of the composite application, and wherein the template serves as an input for instantiating the composite application.
2. Description and Disadvantages of Prior Art
In this field the term “composite application” defines an application hosted on a web portal platform which is built by combining and connecting multiple components such as portlets, wikis, document libraries or web services, for a particular purpose such as a shop or a virtual teamroom application. A single portal platform may host multiple instances of the same composite application, for example different teamrooms for different associated user communities. Composite applications are built from a template describing the contained components and their set-up and interconnection.
FIGS. 1A and 1B illustrate a prior art system architecture which is used in prior art for building a composite application.
FIG. 1A shows the overview of the components that build up the prior art application infrastructure 11,—abbreviated herein also as AI—system architecture within an overall portal system 10. The application infrastructure comprises:                the templating application infrastructure 13—abbreviated herein also as TAI—that handles the templates in the system and the creation of new composite applications,        the composite application infrastructure 15—abbreviated herein also as CAI—that handles the application instances 19 during runtime and manages connections and the data flow between the components of an application,        the component registry 27 that manages the business components installed in the system, and        the portal handler 29 which is a specific local component that manages any portal related artifacts 8 like pages or portlets for the application infrastructure in the portal, and which is used by the instantiation component 17 to create such artifacts during the creation of a new composite application.        
The templating application infrastructure (TAI) component 13 manages the templates 23 in the system which contain references to instantiable components in a local list of components 27. As an example, a template for shopping applications could consist of a reference to a document library component which is used to hold the available goods and their descriptions, a shop portlet that lets clients process actual shopping transactions, an invoice business component that handles the payment process and a blogging component that allows clients to comment on their satisfaction.
The TAI component 13 also creates application instances from the templates via an instantiation component 17, which creates separate instances of the referenced business components, typically by creating or copying individual configurations for these components such that multiple application instances can be created from the same template without interfering with each other.
For the above mentioned sample template, the instantiation 17 would, among other things, create an individual storage compartment in the document library, an individual configuration of the invoice component referring to the bank account and an individual configuration for the shop portlet that is set up to display goods from the created document library and to delegate payment processing to the created invoice component instance.
In particular, the instantiation 17 needs to create the necessary portal artifacts like pages that allow to interact with the created composite application, which is typically done by employing a specific handler 29 that creates those portal artifacts 8 and links them with the business components of the application.
The created composite application instances 19 hold a context 25 that lists the component instances that make up the composite application
FIG. 1B shows an overview of the storage components involved in the portal architecture 10 that comprises deployment related code in a deployment component 14 and a runtime environment in one or more runtime containers 12 where the deployed components are executed.
For the composite application context deployed artifacts are:                application components stored in a component registry 18,        templates stored in a template catalog 20.        
This data is then referenced by the application's instance specific data 16.
In prior art composite applications and their components which are also referred herein as “artifacts” have to be individually developed or supplied by a vendor. Specifically, when different composite applications or artifacts are offered by different vendors a decision which composite application or artifact to use for building up a new, own composite application requires significant knowledge about the properties of the artifacts offered by the various vendors. These properties comprise the scope of functions, an artifact is able to deliver, compliant of input data and output data in order to build in an artifact into the planned own composite application, as well as precise descriptions of APIs to other artifacts or components cooperating with. This is the reason why such artifacts need to be manually observed, analyzed and finally deployed. Further, a planned composite application needs then to be manually assembled by using the artifact mentioned above. The assembly can then be stored as a template.
Alternatively, composite applications can also be created based on templates that contain the list of components that build up the composite application. If any of the respective components is not available in the system the creation of the composite application will fail. So, always, some manual work is necessary for creating a composite application.
Disadvantageously, this manual work requires much skills and experience. Further, in case of updates for certain artifacts which have been used for building up the composite applications it is a difficult work to observe and analyze if such new update is suitable for being build in an existing composite application in order to replace an older version thereof. Again, the functional scope must be analyzed, the interfaces must be observed in order to comply with those being used in the actually existing composite application and, potentially, a decision has to be taken if or if not to extend the composite application in order to integrate some new function offered by such new update of an artifact as mentioned above.
Disadvantageously, the assembly and keeping up-to-date of such composite applications is to much time-consuming.